Extensible and context-aware commanding infrastructure

ABSTRACT

Computing systems in which multiple non-context-sensitive or core commands may be initiated from each of a number of different user interface contexts. There are also multiple context-sensitive mechanism for visualizing the commands depending on which of the multiple possible user interface contexts that the commands appear. At least some embodiments described herein also related to the presentation of dialogs at various stages of the command lifecycle without the system needing to know the underlying operations of the command, and allowing the developer to specify when dialogs are to appear in that lifecycle.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of each of the following provisionalpatent applications, and each of the following provisional patentapplications are incorporated herein by reference in their entirety:

-   1. U.S. Provisional Application Ser. No. 61/905,114, filed Nov. 15,    2013;-   2. U.S. Provisional Application Ser. No. 61/884,743, filed Sep. 30,    2013;-   3. U.S. Provisional Application Ser. No. 61/905,111, filed Nov. 15,    2013;-   4. U.S. Provisional Application Ser. No. 61/905,243, filed Nov. 17,    2013;-   5. U.S. Provisional Application Ser. No. 61/905,116, filed Nov. 15,    2013;-   6. U.S. Provisional Application Ser. No. 61/905,129, filed Nov. 15,    2013;-   7. U.S. Provisional Application Ser. No. 61/905,105, filed Nov. 15,    2013;-   8. U.S. Provisional Application Ser. No. 61/905,247, filed Nov. 17,    2013;-   9. U.S. Provisional Application Ser. No. 61/905,101, filed Nov. 15,    2013;-   10. U.S. Provisional Application Ser. No. 61/905,128, filed Nov. 15,    2013; and-   11. U.S. Provisional Application Ser. No. 61/905,119, filed Nov. 15,    2013.

BACKGROUND

Computing systems and networks have transformed the way we work, play,and communicate. Computing systems obtain there functionality byexecuting commands on computing resources accessible to the computingsystem. Commands might be, for instance, initiated by a user. In thatcase, the user interfaces with a visualization of the command, therebycausing corresponding operations on the computing asset. During variousstages of the lifecycle of a command, the user may be presented withdialogs that ask for confirmation, inform of success or failure, orinform of progress of the command.

BRIEF SUMMARY

At least some embodiments described herein relate to computing systemsin which multiple non-context-sensitive or core commands may beinitiated from each of a number of different user interface contexts.There are also multiple context-sensitive mechanism for visualizing thecommands depending on which of the multiple possible user interfacecontexts that the commands appear. At least some embodiments describedherein also related to the presentation of dialogs at various stages ofthe command lifecycle without the system needing to know the underlyingoperations of the command, and allowing the developer to specify whendialogs are to appear in that lifecycle.

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and otheradvantages and features of the invention can be obtained, a moreparticular description of the invention briefly described above will berendered by reference to specific embodiments thereof which areillustrated in the appended drawings. Understanding that these drawingsdepict only typical embodiments of the invention and are not thereforeto be considered to be limiting of its scope, the invention will bedescribed and explained with additional specificity and detail throughthe use of the accompanying drawings in which:

FIG. 1 abstractly illustrates an example computing system in which theprinciples described herein may be employed;

FIG. 2 illustrates a user interface element in the form of a blade, andin which commands are displayed in a command bar;

FIG. 3 illustrates a user interface that represents modifications to theuser interface that would occur if the user selects the command barexpansion control of FIG. 2;

FIG. 4 illustrates an example context menu that represents anotherexample of a context-sensitive mechanism for visualizing controls;

FIG. 5 illustrates an extended example context menu that representsanother example of a context-sensitive mechanism for visualizingcontrols;

FIGS. 6A through 6D illustrates various visualizations of the samecommands across different user interface contexts;

FIG. 7 illustrates that the commands within FIGS. 6A through 6D areindeed the same;

Even though the user experience for displaying the commands and thecontext where the command is displayed may be different, the actualcommand is the same as illustrated in FIG. 7;

FIG. 8 illustrates a life-cycle that the system may be aware of for allcommands, whether built-in or extrinsic;

FIG. 9 illustrates an example of a dialog that may appear uponinitiating a stop website command; and

FIG. 10 illustrates that each stage in a life cycle of a command cansurface a different dialog, with the application developer indicatingwhether the corresponding dialog is to appear at each stage in the statemachine.

DETAILED DESCRIPTION

Commanding is a common way of describing behavior in a system, whetherdistributed or otherwise. Each command represents a unit offunctionality that can be applicable to an asset within the system, tothe system itself, or to any arbitrary artifact. Commands can beprovided by the system (i.e., built-in commands) or by other parties(extrinsic commands).

In accordance with the principles described herein, commands areprovided consistently in an entire system, even though the system itselfmay be operating a number of different applications composed by entirelydifferent parties. Furthermore, the embodiments described herein helpsecurity by running commands in the right isolation mode, such thatharmful (but not necessarily malicious) code does not compromise thesystem. Preferably, the command should not block the user interface sothey should run asynchronously. As far as the user experience, theembodiments described herein allow commands to be surfaced following thesame patterns (e.g. command bar; context menu; etc.) (i.e., alsoreferred to herein as a context-sensitive mechanism for visualization)and provide interactivity options to the users (e.g. dialogs) so theycan participate in the operation and also understand the operation'sstatus and result.

The principles described herein may be implemented using a computingsystem. For instance, the users may be engaging with the system using aclient computing system. The executable logic supporting the system andproviding visualizations thereon may also be performed using a computingsystem. The computing system may even be distributed. Accordingly, abrief description of a computing system will now be provided.

Computing systems are now increasingly taking a wide variety of forms.Computing systems may, for example, be handheld devices, appliances,laptop computers, desktop computers, mainframes, distributed computingsystems, or even devices that have not conventionally been considered acomputing system. In this description and in the claims, the term“computing system” is defined broadly as including any device or system(or combination thereof) that includes at least one physical andtangible processor, and a physical and tangible memory capable of havingthereon computer-executable instructions that may be executed by theprocessor. The memory may take any form and may depend on the nature andform of the computing system. A computing system may be distributed overa network environment and may include multiple constituent computingsystems. An example computing system is illustrated in FIG. 1.

As illustrated in FIG. 1, in its most basic configuration, a computingsystem 100 typically includes at least one processing unit 102 andmemory 104. The memory 104 may be physical system memory, which may bevolatile, non-volatile, or some combination of the two. The term“memory” may also be used herein to refer to non-volatile mass storagesuch as physical storage media. If the computing system is distributed,the processing, memory and/or storage capability may be distributed aswell. As used herein, the term “executable module” or “executablecomponent” can refer to software objects, routines, or methods that maybe executed on the computing system. The different components, modules,engines, and services described herein may be implemented as objects orprocesses that execute on the computing system (e.g., as separatethreads).

In the description that follows, embodiments are described withreference to acts that are performed by one or more computing systems.If such acts are implemented in software, one or more processors of theassociated computing system that performs the act direct the operationof the computing system in response to having executedcomputer-executable instructions. For example, such computer-executableinstructions may be embodied on one or more computer-readable media thatform a computer program product. An example of such an operationinvolves the manipulation of data. The computer-executable instructions(and the manipulated data) may be stored in the memory 104 of thecomputing system 100. Computing system 100 may also containcommunication channels 108 that allow the computing system 100 tocommunicate with other message processors over, for example, network110.

The computing system 100 also includes a display 112 on which a userinterface, such as the user interfaces described herein, may berendered. Such user interfaces may be generated in computer hardware orother computer-represented form prior to rendering. The presentationand/or rendering of such user interfaces may be performed by thecomputing system 100 by having the processing unit(s) 102 execute one ormore computer-executable instructions that are embodied on one or morecomputer-readable media. Such computer-readable media may form all or apart of a computer program product.

Embodiments described herein may comprise or utilize a special purposeor general-purpose computer including computer hardware, such as, forexample, one or more processors and system memory, as discussed ingreater detail below. Embodiments described herein also include physicaland other computer-readable media for carrying or storingcomputer-executable instructions and/or data structures. Suchcomputer-readable media can be any available media that can be accessedby a general purpose or special purpose computer system.Computer-readable media that store computer-executable instructions arephysical storage media. Computer-readable media that carrycomputer-executable instructions are transmission media. Thus, by way ofexample, and not limitation, embodiments of the invention can compriseat least two distinctly different kinds of computer-readable media:computer storage media and transmission media.

Computer storage media includes RAM, ROM, EEPROM, CD-ROM or otheroptical disk storage, magnetic disk storage or other magnetic storagedevices, or any other tangible medium which can be used to store desiredprogram code means in the form of computer-executable instructions ordata structures and which can be accessed by a general purpose orspecial purpose computer.

A “network” is defined as one or more data links that enable thetransport of electronic data between computer systems and/or modulesand/or other electronic devices. When information is transferred orprovided over a network or another communications connection (eitherhardwired, wireless, or a combination of hardwired or wireless) to acomputer, the computer properly views the connection as a transmissionmedium. Transmissions media can include a network and/or data linkswhich can be used to carry or desired program code means in the form ofcomputer-executable instructions or data structures and which can beaccessed by a general purpose or special purpose computer. Combinationsof the above should also be included within the scope ofcomputer-readable media.

Further, upon reaching various computer system components, program codemeans in the form of computer-executable instructions or data structurescan be transferred automatically from transmission media to computerstorage media (or vice versa). For example, computer-executableinstructions or data structures received over a network or data link canbe buffered in RAM within a network interface module (e.g., a “NIC”),and then eventually transferred to computer system RAM and/or to lessvolatile computer storage media at a computer system. Thus, it should beunderstood that computer storage media can be included in computersystem components that also (or even primarily) utilize transmissionmedia.

Computer-executable instructions comprise, for example, instructions anddata which, when executed at a processor, cause a general purposecomputer, special purpose computer, or special purpose processing deviceto perform a certain function or group of functions. The computerexecutable instructions may be, for example, binaries, intermediateformat instructions such as assembly language, or even source code.Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the described features or acts described above.Rather, the described features and acts are disclosed as example formsof implementing the claims.

Those skilled in the art will appreciate that the invention may bepracticed in network computing environments with many types of computersystem configurations, including, personal computers, desktop computers,laptop computers, message processors, hand-held devices, multi-processorsystems, microprocessor-based or programmable consumer electronics,network PCs, minicomputers, mainframe computers, mobile telephones,PDAs, pagers, routers, switches, and the like. The invention may also bepracticed in distributed system environments where local and remotecomputer systems, which are linked (either by hardwired data links,wireless data links, or by a combination of hardwired and wireless datalinks) through a network, both perform tasks. In a distributed systemenvironment, program modules may be located in both local and remotememory storage devices.

In accordance with principles described herein, a user interface element(often called herein a “part”) represents a basic unit of the userinterface. Each of at least some of the parts are associated withcorresponding controls that the user may interact with to thereby causethe system to execute respective commands. The execution of the commandmay, for instance, return data to project via the corresponding part.The parts may incorporate extrinsic commands that implement givencontracts, and may reason about them.

In accordance with the principles described herein, commands (alsocalled hereinafter “non-context-sensitive commands” or “core commands”)can be associated with resources in the system (such as a website,database, an arbitrary artifact, the system itself, or a piece of theuser interface). This association may be persistent, such that when thatresource is displayed in different user interface contexts, thenon-context-sensitive commands associated with that resource are stillavailable, but displayed using the right context-sensitive mechanism.For instance, the context-sensitive mechanism for visualizing these corecommands may be a user experience form factor appropriate for thecontext in which the part is displayed. Consistency may also be furtherachieved by having the same context-visualization mechanism used todisplay the commands of any user interface element that is displayed ina particular user interface context. Commands are thus offered to theuser via a well-defined experience that is consistent across the entiresystem.

The system provides a set of abstractions through a portal that enableapplication developers to create commands. A command encapsulates anaction in the system. The composition tree describes structure and thecommands describe behavior. Commands provide a well-defined surface thatthe system can reason about to support units of behavior. Commands canbe system commands (built-in) and custom commands (provided by theapplication developer). Commands are offered to the user via awell-defined experience that is consistent across the entire system.This experience is built-in and cannot be redefined by applicationdevelopers. Application developers can only contribute with newcommands, but not with new ways of exposing those commands to the user.Thus, the manner of exposing commands (the command experience) isgoverned by the system.

Commands provide application developers and users a consistent modelacross applications (sometimes referred to as “extensions”) compatiblewith browser capabilities and scalable to all parties to describebehavior in the system. The command may have affinity with portal assetswhich can make them available everywhere that asset is presented if sodesired

The user interface may be a rich in allowing different user interfaceelements to be presented in entirely different contexts. For instance,as will be described further below, the user interface might includedifferent contexts such as a favorites area, a blade, and hubs. Theserepresent different places where user interface elements (also calledherein “parts”) can be displayed. The commands associated with a givenasset can be available in all of these different contexts, enablingtaking action on a resource in the way that is more convenient (and inaddition new commands can be added to accommodate the specifics of eachcontext in case is needed).

Commands can be associated with different resources in the system. Forinstance, the resource might be a portion of the user interface itself,such as a part. As another example of a portion of the user interfacemay be what will be referred to herein as a “blade”. A blade is a userinterface element that may be placed on a canvas that extends in anextendible direction (such as horizontally). For substantially all of aparticular range of the canvas in the dimension of the extendibledimension, the blade may occupy substantially all of the canvas in thedimension perpendicular to the extendible direction of the canvas. Theresource might also be associated with an actual asset in the system,such as a website, database, virtual machine, and so forth. Blades orother parts can be also associated with assets creating a transitiverelationship between the commands and its container if so desired.

Commands are visualized through different context-sensitive mechanisms,depending on the user interface context in which the associated part isdisplayed. Each context-sensitive mechanism supports a particular userexperience. For instance, FIG. 2 illustrates a user interface element200 in the form of a blade. The blade is associated with an asset in theform of a website (called “thisisanothersite1” in the user interfaceelement 200 of FIG. 2). Commands are presented in a command bar 210 atthe top of the blade in this context. Thus, the command bar 210represents a context-sensitive mechanism for visualizing commands whenthe commands are displayed in the context of a blade.

In FIG. 2, the command bar 210 is illustrated as visualizing threenon-context-sensitive commands including the start command 211, the stopcommand 212, and the restart command 213. The start command 211 isdeemphasized as not selectable since the web site has already running asevidenced within the status window 230. As will be seen from thesubsequent windows, the command 211, 212 and 213 are“non-context-sensitive” in that regardless of the user interface contextin which the non-context-sensitive commands are displayed, at least theselectable non-context-sensitive commands (in this case stop command 212and the restart command 213) will still be displayed.

The command bar 210 also includes an overflow control 221 (also calledhereinafter a “command bar expansion control 221”) that is presentedwhen there are more commands associated with the blade than the bladecan display in the available space. FIG. 3 illustrates a user interface300 that represents modifications to the user interface 200 that wouldoccur if the user selects the command bar expansion control 221. Notethat the command bar 210 is augmented to be an augmented command bar 310that shows a second row of commands. For instance, anon-context-sensitive delete command 214 is illustrated in the secondrow.

The selectable non-context-sensitive commands 212 through 214 may bepresented regardless of where commands appears in the user interfacecontext. For instance, when the user interface element is associatedwith a resource, the non-context sensitive commands may be basiccommands associated with the resource that the user might like toinitiate regardless of the user interface context in which the resourceis presented. For instance, a user might like to start, stop, restart,or delete a web site from any one of a number of different userinterface contexts.

Referring again to FIGS. 2 and 3, the command bars 210 and 310 alsoinclude context-sensitive commands. For instance, there is an overflowindicator 221 (hereinafter referred to as a “command bar expand command”221). Furthermore, there is a browse command 222, which is related tothe underlying asset (e.g., the web site), but which is specific to apresentation in a particular user interface context. For instance, auser might like to browse to the web site when the web site isassociated with the blade (since there is more space available tousefully browse), but the user might not be so interested in browsing ifthey are working in the context of a smaller user interface portion thatis associated with that web site. Another context-sensitive command isillustrated as the reset publish profile command 223 in FIG. 3. FIG. 3illustrates another context-sensitive command in the form of a commandbar collapse control 224, which when selected returns the user interface300 to that of the user interface 200 of FIG. 2.

In one embodiment, context-sensitive commands including one or moreof 1) non-selectable non-context-sensitive commands (such as the startcommand 211), 2) commands that are associated with an underlyingresource, but which are not to be performed in every user interfacecontext (such as the browse command 222 and the reset publish profilecommand 223), and 3) and commands that are associated with the userinterface element itself, but not the underlying resource (such as theoverflow indicator 221 or command bar expansion command).

FIGS. 2 and 3 illustrate user interface elements when web commands areassociated with a blade, which is one example of a user interfacecontext. However, web commands may be displayed in other user interfacecontexts. For instance, suppose that the web commands are in a smalleruser interface part that is within the favorites area, within anactivity pane or grid. In those user interface contexts, the activecontext sensitive commands may be displayed in a context menu. FIG. 4illustrates an example context menu 400.

The context menu 400 again visualizes the active non-context-sensitivecommands, including the stop command 412 (corresponds to stop command212 of FIG. 2), the restart command 413 (corresponding to the restartcommand 213 of FIG. 2), and the delete command 414 (corresponding to thedelete command 214 of FIG. 3). Because the state of the underlyingresource (i.e., the web site) was persisted, the system recognized thatthe start command is not a selectable command given the current state ofthe resource. Thus, when accessing commands for that same web site viaanother user interface context, the active non-context-sensitivecommands are again displayed. The context menu 400 also includes asingle context-sensitive command in the form of an unpin command 421,which would remove the associated user interface element from the userinterface context.

In this example, the blade user interface element 200 is one example ofa user interface context with the command bar 210 being an associatedcontext-sensitive visualization for the commands. The context menu 400is another example of the associated context-sensitive visualization forthe commands, which is associated with other user interface contexts(such as smaller parts, favorites areas, grids, activity panes, and soforth).

FIG. 5 illustrates another user interface element 500 that represents amore extended context menu. This user interface element 500 might appearwhen accessing commands to operate on the web site from yet another userinterface context. Accordingly, the user interface element 500represents yet a third example context-sensitive mechanism forvisualizing the web commands.

The user interface element 500 again displays the non-context sensitivecommands including the stop command 512 (corresponding to the stopcommand 212 and 412 in FIGS. 2 and 4, respectively), the restart command513 (corresponding to the restart command 213 and 413 in FIGS. 2 and 4,respectively, and the delete command 514 (corresponding to the deletecommand 214 and 414 in FIGS. 3 and 4, respectively). Note that theunderlying resource is the web site, and the state of the web site hasbeen preserved. Accordingly, the start command 511 (corresponding to thestart command 211 of FIG. 2) is displayed, but in deemphasized form. Thebrowse command (corresponding to browse command 222 of FIG. 2), and thereset publish profile command 523 (corresponding to the reset publishprofile command 223 of FIG. 2), are also displayed, even though they arecontext-sensitive commands.

The commands 511 through 514, 522 and 523 are application commands 510(also referred to herein as “extrinsic commands”) being offered byapplication developers and not underlying system. The extended contextmenu 500 also includes system commands 530, such as an unpin command531, and size selection commands 522 through 524. Such system commands530 are offered by the system regardless of the underlying resource, solong as the commands were selected within the given user interfacecontext that generated the extended context menu 500.

The built-in commands provide general infrastructure services (pin/unpinparts, resizing parts, restoring layout, and so forth) and are generalin that they apply across all usage domains. Commands provided byapplication developers are domain specific. For instance, an example setof extrinsic commands for a web site application might include “start”,“stop”, “delete website” and so forth.

Commands are authored by application developers by leveraging a set ofartifacts (interfaces and bases classes provided by the system) thatexpose the command contract to the application developers. This allowsthe application developer to provide the actual behavior of the command(what happens when the command is executed), provide dialogs (which areoptional) that will display at different moments of the command's lifecycle, and influence the command life-cycle.

The non-context-sensitive commands can follow a resource in multiplecontexts. For example, commands associated with a website can be presentin the website's blade (see FIG. 6A), in the website startboard part(see FIG. 6B), when the website is displayed in a grid (see FIG. 6C), inthe notifications panel, when the website is part of a search result(see FIG. 6D) or anywhere the website is surfaced. Note that the statusof the underlying resource is considered in each of FIGS. 6A through 6D,in that a start command is not offered given that the web site hasalready started. Furthermore, note that the stop command, the restartcommand, and the delete command are offered regardless of the userinterface context in which the commands and associated resource arevisualized. Each of FIGS. 6A through 6B illustrate thenon-context-sensitive commands being displayed via a differentcontext-sensitive mechanism as a result of being in a different userinterface context. Even though the user experience for displaying thecommands and the context where the command is displayed may bedifferent, the actual command is the same as illustrated in FIG. 7.

FIG. 8 illustrates a life-cycle 800 that the system may be aware of forall commands, whether built-in or extrinsic. The life-cycle 800 may betracked by, for example, a command state tracking module, which may be asingle module or a collection of modules.

Before the command is initiated, there is no operation, which is thenone state 801 in FIG. 8. When the command is initiated, the statetransitions 811 to a pending state 802. In the pending state, thecommand is in process, and the results are pending. If the command iscancelled (transition 812), then the operation ends transitioning to theNone state 801. If the operation completes and is successful (transition813), the result is success (the “Success” state 803 in FIG. 8).Otherwise, if the operation is not successful (transition 814), theresult is failure (the “Failure” state 804 in FIG. 4). The systemunderstands this lifecycle even without understanding what specificallythe underlying operation(s) of the command are doing.

The developer can specify whether or not constrained user interfaceelements (or dialogs) are to appear at each of the transition 811through 814 for each command. Accordingly, when making a transition 811through 814, the system can check to determine whether a dialog is toappear as part of the transition. For instance, such dialogs could askusers for confirmations, inform of progress, or inform of the result ofan operation, all depending on which transition 811 through 814 is beingmade, and what the resource associated with the command is.

FIG. 9 illustrates an example of a dialog 900. In this example, thesystem is aware that the user has selected a stop command. The systemmay then track the overall lifecycle 800 of the stop command even thoughthe system might not be aware of all that is involved in stopping theweb site. The system is also aware of the resource type being operatedupon (i.e., a web site) as well as an identifier for that resource(“Wandering”).

Immediately upon receiving the stop command, the stop command beginstransitioning (as represented by transition 811) from the Non state 801to the Pending state 802. However, as part of this transition, theauthor verifies that the browser developer has not indicated that adialog is to appear at this point for this type of resource (e.g.,website), and/or that the web site developer has not indicated that adialog is to appear at this point for that particular resource (e.g.,the “Wandering website”). The browser developer and/or the websiteauthor may also specify a dialog template in cases in which there aremultiple templates that could be used for that transition and resourcetype.

Here, the system verifies that a dialog is to appear, and thus presentsdialog 900. The dialog 900 may be generated knowing nothing more thanwhich transition is involved (and potentially also a dialog template touse which may also be specified by the developer). The dialog 900 maythen populate the dialog template using the name of the resource (e.g.,“Wandering” website), and then present the dialog to the user. Thus, thepresentation of dialogs may be consistent throughout the systemregardless of the command being executed, or the resource being operatedupon, even without the system knowing the specifics of the underlyingoperations that support the command.

These dialogs are data-driven and extremely constrained to provide auniform user experience across applications. Dialogs includeconfirmation (with yes/no buttons), show progress (deterministic andnon-deterministic), show success, and show failure (with a retrybutton). Application developers can configure the command to surface thedialogs at certain points in the lifecycle of the operation.

As illustrated in FIG. 10, each stage in the life cycle can surface adifferent dialog, with the application developer indicating whether thecorresponding dialog is to appear at each stage in the state machine.

In some cases, the portal can provide abstractions that applicationdevelopers can use to create intrinsic commands that the system willrecognize (at least to the point of being able to track the statemachine of FIG. 10). An example can be extensible abstractions for“Save” and “Discard” commands that when used in forms are subject to thevalidation state and changes to the underlying form.

Commands are executed asynchronously by the system. Commands provided byapplication authors are executed leveraging the system's isolation modelto ensure that they do not compromise the overall portal (as theexecution is isolated within the application that owns the command).

The application developer creates a small set of commands that areavailable in multiple contexts. All capabilities for his commands(execution logic, dialogs, and so forth) are preserved and the necessaryuser experience is adapted to the constraints of where the command isrendered. This makes possible that users can interact with a resource atany place in the user interface. There is no single location where“actions” can be executed but rather any place in the portal allows richinteractions with resources.

Accordingly, a system has been described that provides consistency inhow commands are visualized, as well as how dialogs associated with thecommand lifecycle are visualized. This is true regardless of there beinguser interface elements of different applications within the system.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive. The scope of the invention is, therefore, indicatedby the appended claims rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

What is claimed is:
 1. A computer program product comprising one or morecomputer-readable storage media having thereon computer-executableinstructions that are structured such that, when executed by one or moreprocessors of a computing system, cause the computing system toinstantiate and/or operate the following: a plurality ofnon-context-sensitive commands that may be initiated from each of aplurality of user interface contexts; and a plurality ofcontext-sensitive mechanisms for visualizing the plurality ofnon-context-sensitive commands depending on which of the plurality ofuser interface contexts in which the plurality non-context sensitivecommands appear.
 2. The computer program product in accordance withclaim 1, the plurality of non-context-sensitive commands beingassociated with a resource upon which each of the plurality ofnon-context-sensitive commands acts when selected.
 3. The computerprogram product in accordance with claim 1, the one or morecomputer-readable storage media having thereon computer-executableinstructions that are structured such that, when executed by one or moreprocessors of a computing system, cause the computing system to furtherinstantiate and/or operate the following: one or more context-sensitivecommands visualized with the plurality of non-context-sensitivecommands, but which may differ depending on which of the plurality ofuser interface contexts in which the plurality of non-context-sensitivecommands appear.
 4. The computer program product in accordance withclaim 1, the different contexts in the user interface including a firstset of one or more contexts associated with a first application, and asecond set of one or more contexts associated with a second application.5. The computer program product in accordance with claim 4, the firstset of one or more contexts associated with the first applicationincluding a first context of a particular context type, and the secondset of one or more contexts associated with the second application alsoincluding a second context also of the same particular context type. 6.The computer program product in accordance with claim 5, any context ofthe particular context type being associated with a particularcontext-sensitive mechanism for visualizing the plurality ofnon-context-sensitive commands, such that the mechanism for visualizingthe plurality of non-context-sensitive commands is the same in the firstcontext of the particular context type and associated with the firstapplication as the mechanism for visualizing the plurality ofnon-context-sensitive commands in the second context of the particularcontext type and associated with the second application.
 7. The computerprogram product in accordance with claim 1, the plurality ofnon-context-sensitive commands being a first plurality ofnon-context-sensitive commands, the one or more computer-readablestorage media further having thereon computer-executable instructionsthat are structured such that, when executed by one or more processorsof the computing system, cause the computing system to instantiateand/or operate the following: a second plurality ofnon-context-sensitive commands that may be initiated from each of theplurality of user interface contexts; the plurality of context-sensitivemechanisms also for visualizing the second plurality ofnon-context-sensitive commands, such that for a given user interfacecontext, the same context-sensitive mechanism is used to visualize thefirst plurality of non-context-sensitive commands as would be used tovisualize the second plurality of non-context-sensitive commands in thatgiven user interface context.
 8. The computer program product inaccordance with claim 1, the plurality of non-context-sensitive commandsbeing selectable from a user interface element, the execution of atleast one of the plurality of non-context-sensitive commands resultingin a change in data displayed in the user interface element.
 9. Thecomputer program product in accordance with claim 1, the plurality ofcontext-sensitive mechanisms being intrinsic to a system, and notalterable by applications running within the system.
 10. A method forexecuting a command from a user interface element, the methodcomprising: an act of initiating the command; and an act of tracking thecommand at a plurality of stages; for each of the plurality of stages,determining whether a dialog is indicated as to be displayed, and if so,displaying a dialog for the corresponding stage that is consistentacross a plurality of commands.
 11. The method in accordance with claim10, the method being performed by a command state tracking module, andthe command being a first command, the method further comprising: an actof initiating a second command; and an act of tracking the secondcommand at a plurality of stages of the second command that are the sameas the plurality of stages of the first command; for each of theplurality of stages of the second command, determining whether a dialogis indicated as to be displayed, and if so, displaying a dialog for thecorresponding stage that is consistent across a plurality of commands.12. The method in accordance with claim 11, the first and secondcommands both being intrinsic commands.
 13. The method in accordancewith claim 11, the first and second commands both being extrinsiccommands.
 14. The method in accordance with claim 11, one of the firstand second commands being an extrinsic command, and the other of thefirst and second commands being an intrinsic command.
 15. The method inaccordance with claim 10, wherein the act of determining whether adialog is to be displayed is performed at least at each transitionbetween the plurality of stages.
 16. The method in accordance with claim15, the determination of whether or not to display a dialog beingprovided by a developer.
 17. The method in accordance with claim 15, theact of displaying the dialog performed at each transition being afunction of the transition.
 18. The method in accordance with claim 10,the act of displaying the dialog being a function of a resource that isbeing operated upon.
 19. A computer program product comprising one ormore computer-readable storage media having thereon computer-executableinstructions that are structured such that, when executed by one or moreprocessors of a computing system, cause the computing system to performa method for executing a command from a user interface element, themethod comprising: an act of initiating the command; and an act oftracking the command at a plurality of stages; for each of the pluralityof stages, an act of determining whether a dialog is indicated as to bedisplayed, and if so, displaying a dialog for the corresponding stagethat is consistent across a plurality of commands.
 20. The computerprogram product in accordance with claim 19, the plurality of commandsincluding a plurality of extrinsic commands and a plurality of intrinsiccommands.